Applications on network devices (such as computer systems connected over a network) can create connections among each other over which they can exchange streams of data in the form of data packets. A data packet is a unit of information transmitted as a discrete entity between devices over the network. To achieve high-speed and high-performance of data packet processing, it is common to parallelize the processing so that network devices can execute more than one thread (e.g., a separate stream of packet execution that takes place simultaneously with and independently from other processing) simultaneously on a multi-processing platform. Multi-processing is useful when a single task takes a long time to complete and processing packets serially (e.g., one at a time) would slow down the overall packet throughput. In a multiprocessing system, packets can be queued to network contexts (e.g., data structures that queue data packets that belong to the same network connection) for further processing based on some kind of algorithm. As a result, data packets that belong to a single connection (such as, for example, a Transmission Control Protocol (TCP) connection) are queued to a single network context, and thus are processed by a single network thread. Data packets that belong to different network connections may be processed by different network threads.
Conventionally, after connection is established between two network devices, data packets for a particular connection are received by network drivers at a destination network device. The network drivers execute driver threads to queue the received data packets and call a packet classifier. The packet classifier, in turn, is responsible for maintaining a pool of network threads and their associated network contexts. The packet classifier receives a data packet, calculates a hash based on a 3-tuple (source IP address, source port, and destination port) indicated in the packet, and uses the calculated value to identify a network context to which the data packets arriving on the connection has to be queued. The following hash function can be used:
y=hash1(x);
wherein ‘x’ is a combination of a source IP address, source port, and destination port indicated in the packet; ‘y’ represents a hash number, which then becomes an input to another function, which maps the hash to a network context number ‘y1’ as follows:
y1=map_hash_q(y);
wherein “q” represents a network context queue.
A network thread picks up the packet and performs TCP processing. A TCP module of the destination network device receives the data packet and the network context and determines TCP connection to which the data packet belongs. It does so by calculating a hash value based on a 3-tuple (using the same hash function that the packet classifier was using). The TCP module uses the hash to index into a TCP hash table (such as TCP table 500 shown in FIG. 5) to obtain a protocol control block (PCB) corresponding to the connection (each PCB stores information related to one TCP connection, such as establishing a connection, managing data transmission via data packets, managing data receipt, and termination of the connection). A TCP table represents an array, with each index in the array being a linked list of PCBs. An index is also referred to herein as a “hash bucket.”
Thus, conventionally, the packet classifier and the TCP module share the same hash function to perform its processing. The rational for doing this is as follows. Since in multiprocessing systems, all network threads access the TCP hash table at the same time, the TCP hash table has to be protected from access conflicts. The TCP hash table can be protected by ensuring that no two threads access the same data structure at the same time. This can be done by locking the data structure or by ensuring that no two threads can access the same PCB at the same time. Locking, however, is a very cumbersome mechanism to implement. Thus, one feasible alternative to locking is to ensure that a particular hash index ‘y’ is accessed only by a particular network thread. This can be done by segmenting a single TCP hash table into different network context queues by using a single hash function y=hash(x) (as described above) as follows:
y=hash(x), y1=map_hash_q(y);
where ‘x’ is a logical summation of a destination port, source port and source address of a particular TCP connection; ‘y’ is the hash index to the TCP hash table; ‘y1’ is an identifier of a network context queue for a particular network thread. Since ‘y’ is always the same for a given x, a particular TCP connection always gets mapped to the same network context queue y1.
Since a hash index ‘y’ is uniquely mapped to a network context ‘y1’, all the connections in hash bucket ‘y’ are assigned to a network context ‘y1.’ As a result, a network thread processing connections in a different network context will not be able to access data related to connections queued to a network context ‘y1.’ This ensured that no locks are needed to access TCP hash table in a multiprocessing system.
However, using the same hash function by the TCP module and by the packet classifier limits the ability of applications to decide how they want their data packets to be processed. Since in prior art implementations the load balancing of connections was achieved by using the default hash algorithm for all TCP connections in general and did not differentiate between TCP connections of one application and another application, connections of a particular application were not load balanced. Furthermore, an application may want data packets that belong to the same session, but to different connections, to be processed by the same network thread. Currently, applications do not have this capability, and data packets that belong to the same session, but to different connections, might be processed by different network threads and then reassembled after processing is completed. This, in turn, slows down performance of the multiprocessing device.
Accordingly, what is needed is a mechanism that provides flexibility to applications to distribute connections in a multiprocessing system.